\section{Validation}
\label{sec:Validation}

We have demonstrated the expressive power of our Security Rules (\textsc{Sr}) \textsc{Dsl} by presenting a variety of policy rules based on the Medical System (\textsc{Ms}) (cf. Section \ref{sec:MotivatingExample}). We showed that \textsc{Sr} allows to express obligations, prohibitions and permissions, either state-based or action-based. Contexts, a crucial component of policies, are defined using a rich expression language. A dedicated engine (\cite{Elrakaiby2011,Cuppens2003}) for policy management and analysis (e.g. detecting conflicts, or discovering violations) supports our \textsc{Dsl}. To the best of our knowledge, we are the first team conducting experiments from requirements to code for stateful policies (compared to stateless access control). \SAR also describes a clean way to integrate the different artifacts for enforcing security policy into existing applications. 

In the next future, we will address proper validation of \SAR on real case studies. However for the moment, we wanted to evaluate the viability of our approach regarding performance issues: since \SAR has a runtime orientation, problems may occur when applications size increases. Besides our \textsc{Ms} example, we evaluated our approach on another reasonable sized application: the Auction Sales Management System (\textsc{Asms}), which consists of 122 classes, 797 methods and about 11 kLoC. The \textsc{Asms}  implements an Auction system, where users can buy or sell products online, after joining an auction and placing bids. Users can also post, or read, comments from the Auction session. We specifically targeted performance-related research questions:
\begin{itemize}
	\item does the tool perform sufficiently well to be used in practice? 
	\item what are the main factors impacting the tool performance? 
	\item which optimizations could be needed to improve the tool performance?
\end{itemize}
To answer these questions, our protocol defined a security policy for each example applications and ran a scenario covering the different policy management operations, i.e. obligation activation, violation, policy administration, etc. We evaluated three factors: the time necessary to perform policy update operations; the time to evaluate an access request, and the time to update the (obligation) policy state, with respect to the (dynamic) state size's increasing (i.e. increasing the number of instances for relevant roles) and the (activated) rule instances number increasing. 

Figure \ref{fig:results} shows the results, which are promising. Policy update operations and access request evaluations are performed in a few milliseconds, and represent an almost constant overhead. On the other hand and as expected, obligation processing time increases with the number of (activated) obligations in the system: the activated obligations' contexts have to be verified individually to check whether they are canceled, violated or fulfilled, after each state update. We are currently investigating ways to improve this processing time by using \emph{tabling} technique, basically a memoization technique to store some intermediate steps that are systematically performed when obligation contexts are checked to avoid repeating the same verifications multiple times if unnecessary. Another direction is studying the extension of policy refactoring techniques for access control policies \cite{KatebMTHX12} for policies including both access control and obligation policies.

